Graphical Java Lesson 1-7: Adding Gravity to Mario's World 


For a long time now, Mario has been walking on air. In this lesson, we're going to make Mario fall 
under the influence of gravity, and land on platforms. He will then be able to walk on those platforms. 


Before we start messing around with Mario's movement, let's give Mario some more room to move, by 
changing the size of our program's main window. In your Walking Mario project, go to your 
WalkingMario.4java source file. Let's make our main window 600 pixels wide and 400 pixels 
high. Change ... 


public static final int WINDOW WIDTH = 400; 
public static final ant WINDOW HEIGHT = 180; 


.. to: 


public static final int WINDOW WIDTH = 600; 
public static final int WINDOW HEIGHT = 400; 


Thanks to our use of symbolic constants here, if you run your program, you will see that the Goomba 
adapted to the new size of the window. It now walks all the way to the right side of the bigger main 
window, before it starts to move left. Goombas aren't known for their intelligence, but this one is 
"smart" enough to "know" the new location of the right side of the window. 


Now that we've given Mario some room to fall, let's make him fall! Go to yourMario.java source 
file. Rather than having one universal gravity setting, we'll give Mario his own gravity setting, because 
gravity may affect different characters differently. For example, a Lakitu flies, and is not affected by 
gravity at all. Add the following member variable to your Mario class: 


private int gravity; 


We'll make it a variable, so that it can change, if say Mario gets a power-up that makes him able to 
float. In the constructor of your Mario class, initialize gravity, by adding the following line of 
code: 


gravity = 3; 


What does a gravity of "3" mean? What units are we using here? Here, we're keeping things as simple 
as possible, so every 20 milliseconds (one tick of our timer), Mario will fall 3 pixels. Therefore, the 
influence of gravity on Mario will be measured in pixels per tick. 


Now, let's give Mario the ability to respond to the influence of gravity. Add the following method to 
your Mario class: 


public void respondToGravity () 
{ 
my reck.y = my -reck.y + Gravity; 


} 


Whenever this method is called, Mario will fall gravity pixels, toward the bottom of the screen. 
What does this method do, if gravity is negative? Finally, we need to have our act method call 
respondToGravity, so that every time Mario acts (every 20 milliseconds), he responds to gravity. 
At the end of the body of your act method, add the following line of code: 


respondToGravity(); 


Run your program. As soon as the program starts up, Mario will immediately fall toward the bottom of 
the screen. You can still move left and right, with the left and right arrow keys, but Mario will keep on 
falling, until he's off the bottom of the main window. goom, however, will not fall, since we didn't 
change any code in the Goomba class. 


Mario needs something to land on, like a platform! Let's create a new class: Plat form. Objects of 
type Platform will be "solid". Neither Mario, nor a Goomba will be able to pass through one, from 
any direction. However, this won't stop us from later creating characters, like Boos, that can pass 
through platforms. After you have created the Plat form class, go to your Platform. java source 
file. 


Platforms will be rectangular and of one solid color, so add the following member variables to your 
Platform class: 


private Rectangle my rect; 
private Color my color; 


Import the Rectangle and Color classes, with the following import statements: 


import java.awt 
import java.awt 


.Rectangle; 
~Color; 


ct ct 


Add the following constructor to your Plat form class: 


public Platform(Rectangle r, Color c) 
{ 


my rect = r; 
ny color = ¢7 


} 
We'll also give our Platform class a simple draw method: 
public void draw(Graphics g) 
g.setColor (my color); 
g.fillRect (my rect.x, my rect.y, my rect. width, my rect height) ; 
} 


Import the Graphics class, with the following import statement: 


import java.awt.Graphics; 


Now, let's actually make a platform for Mario to land on. Go to your WalkingMario.java source 
file. For now, our world will only contain one platform, so add the following declaration to your list of 
global variables: 


public static Platform plat; 
In your main method, right after ... 
ctrl = new Controller(); 
... Insert the following line of code: 


plat = new Platform(new Rectangle(0, WINDOW HEIGHT - 10, 
WINDOW WIDTH, 10), Color.BLACK) ; 


Again, you'll need to import the Rectangle and Color classes, with the following import 
statements: 


import java.awt 
import java.awt 


.Rectangle; 
x Color; 


ct ct 


Our platform, plat, will be black, and will cover the bottom 10 pixels of the main window. Let's draw 
it, whenever we repaint the screen. Go to your Content Pane. java source file. At the beginning of 
the paintComponent method of your ContentPane class, insert the following line of code: 


WalkingMario.plat.draw(qg); 
The sequence of draw method calls should look like: 
WalkingMario.plat.draw(g 


) 
WalkingMario.mario.draw(g); 
WalkingMario.goom. draw (gq) 


. 


, 


I decided to have us draw plat behind Mario, so that if Mario "glitches through" the platform, we'll 
be better able to see him. Run your program. You should see a black rectangle at the bottom of the 
window. Mario will fall through it. Mario doesn't land on it, because we haven't written the code for 
that yet! 


When Mario is falling, we want him to stop falling, if he finds himself on top of a platform. What does 
it mean for Mario to be on top of a platform? Mario is on top of a platform, when BOTH of the 
following are true: 


* The bottom of Mario's rectangle is exactly one pixel above the top of the platform's rectangle. 
¢ Mario's horizontal extent (the range of pixels from the left side of Mario's rectangle to the right 
side of his rectangle) shares at least one pixel with the platform's horizontal extent. 


Look at the following diagram: 


The black rectangle represents a platform. If Mario's location is that of one of the green rectangles, he 
is on the platform, because his position, relative to that of the platform, satisfies BOTH of the 
conditions above. However, if Mario's location is that of one of the red rectangles, he is NOT on the 
platform, because his position only satisfies one of the conditions. At position 1, Mario's horizontal 
extent shares at least one pixel with the platform's horizontal extent, but the bottom of Mario's rectangle 
is way above the top of the platform's rectangle. At position 2, the bottom of Mario's rectangle is 


exactly one pixel above the top of the platform's rectangle, but the horizontal extents of Mario and the 
platform do not share any pixels. 


Did you understand all of that? Good, because it only gets HARDER from here! We want to write code 
that will check if Mario is on top of a platform or not. I want to make this code as clear as possible, so 
let's make some accessor methods in our Mario and Platform classes. First, go to your 
Mario.java source file. We'll add four of these "convenience" methods. The first two will get the x- 
coordinates of Mario's left and right sides. Add the following methods to your Mario class: 


public int myLeft () 
{ 


return my _rect.x; 


} 


public int myRight () 
{ 


return my fect .2 + my. rect width — 17 


} 


The next two will get the y-coordinates of Mario's top and bottom. Add the following methods to your 
Mario class: 


public int myTop() 
{ 


return my rect.y; 


} 


public int myBottom() 
{ 


return my Pecloy + my Pectsheight = 1; 


} 


The Platform class will also need these four methods. You can copy their code, and paste it into your 
Platform. java source file, because the code will be EXACTLY the same, in the Plat form class. 
Go to your Platform. java source file, and add the above four methods to your Plat form class. 


In order for Mario to be on top of a platform, his horizontal extent must share at least one pixel with the 
platform's horizontal extent. Checking whether this is the case can be tricky, but I have an idea that will 
make it easier for us. A horizontal extent can be represented as a range of pixels. For example, if the x- 
coordinate of Mario's left side is 117, and the x-coordinate of his right side is 132, his horizontal extent 
can be represented by the range, "117-132". The lower bound of that range is 117, and its upper bound 
is 132. Two ranges (Let's call them "A" and "B".) overlap (share at least one pixel), if: 


* Get the larger of their lower bounds, using the Math .max method. Let's call this value L. 
© This will form the lower bound of the range of pixels shared by ranges A and B. 

* Get the smaller of their upper bounds, using the Math. min method. Let's call this value U. 
© This will form the upper bound of the range of pixels shared by ranges A and B. 

¢ If U—Lis non-negative (greater than or equal to zero), ranges A and B overlap. 


Let's test this algorithm, using 117—132 for range A, and 126—137 for range B: 


¢ The larger of their lower bounds (ZL) is 126. 
¢ The smaller of their upper bounds (U) is 132. 
* U-L=6,so ranges A and B overlap. The range of pixels they share is 126-132. 


Let's test it again, using 117-132 for range A, and 140—150 for range B: 


¢ The larger of their lower bounds (ZL) is 140. 

¢ The smaller of their upper bounds (U) is 132. 

* U-L=-8, so ranges A and B do not overlap. The range of pixels that they would share would 
be "140-132", which wouldn't make sense. 


Finally, we'll test it one more time, using 117—132 for range A, and 90-117 for range B: 


¢ The larger of their lower bounds (ZL) is 117. 

* The smaller of their upper bounds (U) is also 117. 

* U-—L=0, so ranges A and B overlap. They share exactly one pixel, or the range, "117-117". 
Not much of a range, but it still makes sense: "start at 117, end at 117". 


Feel free to test this algorithm some more, with different ranges. Try testing it with a range that is 
aside of he thre eran 712 nd 10 ie shades have tube understanding di 


Now, we will translate our algorithm into code! Create a new class: Range. After you create the 
Range class, go to your Range. java source file. A range will have a lower bound and an upper 
bound, so add the following member variables to your Range class: 


private int lower bound; 
private int upper bound; 


Let's give our Range class the following constructor: 


public Range(int lower, int upper) 
{ 

lower bound = lower; 

upper bound = upper; 


} 


Range's code is going to assume that lower bound-upper_ bound represents a meaningful range 
(lower bound< upper bound). Now, we'll make a method that implements the algorithm we 
tested. Add the following method to your Range class: 


public boolean overlaps (Range other) 

{ 
int lb = Math.max(lower bound, other.lower bound) ; 
int ub = Math.min(upper bound, other.upper bound) ; 
return ub - lb >= 0; 


} 


This method will return t rue, if the ranges represented by the current Range object (this) and 
other overlap. The first line stores the larger of the ranges' lower bounds (LZ) in 1b. The second line 
stores the smaller of the ranges' upper bounds (U) in ub. The method returns whether U — L is non- 
negative. If it's non-negative, the ranges overlap. 


We'll use the Range class in an accessor method that will get Mario's horizontal extent. Go to your 
Mario.java source file. Add the following method to your Mario class: 


public Range horizontalExtent () 


{ 
return new Range(myLeft(), myRight()); 


} 


Our Platform class will also require this method, so go to your Platform. java source file, and 
add it to Plat form. Now, we can FINALLY check whether Mario is on top of a platform or not! Go 
back to your Mario. java source file. Add the following method to your Mario class: 


public boolean isOnAPlatform() 
{ 
return myBottom() == WalkingMario.plat.myTop() - 1 && 
horizontalExtent () .overlaps ( 
WalkingMario.plat.horizontalExtent()); 


} 


This method, using some of the "convenience" methods we wrote earlier, will check whether both of 
the conditions from before are true: 


¢ The bottom of Mario's rectangle is exactly one pixel above the top of plat's rectangle. 
¢ Mario's horizontal extent shares at least one pixel with plat's horizontal extent. 


If both of them are true, Mario is on top of plat. Now, we're going to write code that will allow Mario 
to land on our platform, rather than fall through it. Go to the respondToGravity method of your 
Mario class. We're going to change how Mario responds to gravity. If he's currently on top of a 
platform, he won't move down at all. If he's not on a platform, he'll fall normally. Effectively, when 
Mario is on top of a platform, gravity will be turned off, for him (and him alone!). That doesn't sound 
very realistic, but game programming is all about "making things look right", rather than simulating 
physical processes (like gravitation) as accurately as possible. In your respondToGravity method, 
replace the straightforward ... 


my rect.y = my rect.y + gravity; 
... with the following if statement: 


if (!isOnAPlatform() ) 
my rect.y = my pect.y + Gravity; 


Run your program. Mario will fall, as usual. On my computer, Mario falls right through the platform. 
Check the following line of code, in the constructor of your Mario class: 


my rect = new Rectangle(80, 20, 16, 32); 


This is how it looks, in my program. The top of Mario's rectangle starts 20 pixels below the top of my 
main window's content pane (look at the SECOND number, above). Since Mario is 32 pixels high, the 
bottom of his rectangle starts with a y-coordinate of 51. The top of our platform has a y-coordinate of 
390 (WINDOW HEIGHT - 10). Since his gravity has been set to 3, on every tick of the timer, if he is 
not on top of a platform, he will fall 3 pixels (the y-coordinate of the bottom of his rectangle will 
increase by 3). 


On the first tick of the timer, he will not be on top of the platform (assuming he stays over the platform, 
the y-coordinate of the bottom of his rectangle will need to be 389), so he will fall 3 pixels, and the y- 
coordinate of the bottom of his rectangle will become 54. On the next tick, he will still not be on top of 
the platform, so he will fall another 3 pixels, and the y-coordinate of the bottom of his rectangle will 
become 57. Let's fast-forward through a bunch more ticks: 60, 63, 66, ..., 381, 384, 387. Later, that y- 
coordinate of his will be 387. Since 387 is not equal to 389, he will not be on top of the platform, and 
will therefore fall another 3 pixels. His y-coordinate will become 390. Oops! He just "glitched into" the 
platform! Fast-forwarding through a bunch more ticks: 393, 396, 399, ..., he'll fall right through the 
platform! 


Now, let's change one TINY detail, so that Mario lands on the platform, rather than falling through it. 
Change that 20, in the above line of code, to a 19, so that it looks like: 


My rSct = new Rectangle (80, 19, 16, 32); 


Run your program again. Mario should land on the platform, this time. What gives? The y-coordinate 
of the bottom of Mario's rectangle will start at 50 (19 + 32 — 1). In order for him to land on the 
platform, the y-coordinate will have to become 389. On the first tick of the timer, he will not be on top 
of the platform, so he will fall 3 pixels, and the y-coordinate will become 53. On the next tick, he will 
still not be on top of the platform, so he will fall another 3 pixels. The y-coordinate will become 56. 
Fast-forward through a bunch more ticks: 59, 62, 65, ..., 380, 383, 386. Later, the y-coordinate will be 
386. Since 386 is not equal to 389, he will not be on top of the platform, and will therefore fall another 
3 pixels. His y-coordinate will become 389. On the next tick, he will be on top of the platform, since his 
y-coordinate will be EXACTLY 389! Therefore, he will not fall any more, and can now walk back and 
forth, without falling through the platform. If he walks COMPLETELY off the edge of the platform 
(such that the horizontal extents of Mario and the platform cease to share at least one pixel), though, 
he'll begin to fall again: 392, 395, 398, .... Nothing will break his fall. 


Change the 19, in the above line of code, to an 18, so that it looks like: 
my rect = new Rectangle(80, 18, 16, 32); 


Run your program again. Does Mario land on the platform, or fall through it? What if you then 
change that 18 toa 16? 


The proper functioning of our collision-detection code is SO SENSITIVE to Mario's starting position! 
If Mario doesn't start in "just the right place", he falls right through the platform! Our collision- 
detection code, therefore, is "brittle". If something is brittle, it breaks easily. Collision-detection code is 
one of the most important parts of a platformer game, like Super Mario Bros. If the collision-detection 
code is not "vobust" (resistant to breakage) enough, the entire game becomes a glitchy, unplayable 
mess! 


How can we make our collision-detection code more robust? We could severely constrain Mario's 
movement, so that he only moves at most one pixel, every time our program responds to a timer event. 
However, the movement of every other character would have to be similarly constrained, and that 
would force us to have every character move at the same slow speed. To compensate for this slowness, 
we could decrease the interval between timer events from 20 milliseconds to something less than that. 
It's still not a guarantee, though. You would have to test it out, and what if there were still glitches? 
Plus, what if you later want characters to be able to move at different speeds? 


I have an idea for a more robust collision-detection algorithm. On each tick of the timer, we'll break 
Mario's movement into two stages: Mario's intention to move some number of pixels horizontally and 
vertically, and Mario trying to actually move that many pixels. When Mario tries to actually move that 
many pixels, he'll move about one pixel at a time. Each time he makes one of these "sub-moves", we'll 
check whether he is now "glitched into" one or more platforms. If he "glitches into" a platform, we'll 
undo his last "sub-move", and stop him right there, abutting that platform. If his intended path is clear 
of any obstacles, he'll move the entire distance he intends to move, without a hitch. 


Isn't this just like having Mario move at most one pixel per tick? Sort of, except that all of this 
checking will be invisible to the player. Different characters could intend to move different numbers of 
pixels horizontally and vertically, on each tick. Each character would make the right number of "sub- 
moves" per tick, rather than us having every character move at most one pixel per tick. Thus, the player 
would see different characters move at different velocities, on the screen. 


To implement our robust collision-detection algorithm, instead of having Mario move "directly", we'll 
have Mario intend to move at different velocities, depending on how the player is controlling him, and 
how he is interacting with the environment. In physics, velocity is different from speed. Speed is how 
fast something is moving, while velocity is not only how fast something is moving, but also the 
direction in which it is moving. Speed can be described by a single number, while velocity can be 
described by multiple numbers. The two numbers that we'll use to store the x and y components of 
Mario's velocity will be the components of Mario's velocity vector. A vector is an ordered pair of two 
or more numbers (its components) that can be used, among other things, to specify a velocity. An 
ordered pair is a sequence of numbers in which the order matters. For example, the ordered pair, (1, 2), 
is different from the ordered pair, (2, 1). If Mario is moving 4 pixels to the left and 3 pixels down, the x 
component of his velocity will be -4, and the y component of his velocity will be +3. His velocity 
vector will be the ordered pair, (4, +3). We can also show a vector as an arrow, with a length equal to 
Mario's speed ( / Vio +V - , Where v, and v, are the x and y components of his velocity vector, 
respectively), from the origin of our coordinate system, to a point specified by the components of the 
vector. In other words, we'd draw a dot at (0, 0), a line segment from (0,0) to (v,,v y) , and an 
arrowhead at (v,,v,) . Our example vector would look like: 


po 


yt 


In our coordinate system, that of the screen, values of x increase, as you move to the right, and values 
of y increase, as you move down. As you can see, our arrow goes from (0, 0) to (-4, +3). Given this 


velocity vector, Mario's speed is V(—4)+(3)"=V25=5 _ pixels per tick. 


Now, let's implement the first part of our new collision-detection algorithm. Make sure you are in your 
Mario.java source file. The following member variables will be used to store the x and y 
components of Mario's velocity vector: 


private int * velocity; 
private int y velocity; 


Add them to your Mario class. Now, we're going to refactor our code, so that Mario will first only 
intend to move some number of pixels horizontally and vertically, rather than move "directly". Add the 
following lines of code to your constructor: 


x velocity = 0; 
y velocity = 0; 


Initially, Mario will not intend to move at all. His intentions will soon change, though. Next, we're 
going to change how Mario moves left and right. Right now, given this line of code, in the moveLeft 
method: 


my “eecl.= = my Kect.x — 1; 


If the player wants to move left, Mario will move left one pixel, regardless of anything that might be in 
the way, like a platform. We're going to use platforms as walls, too, since that will be very easy to 
implement. We want to change how Mario moves, so that he is forced to stop, if he runs into a wall, 
while moving left or right. If Mario is trying to move left or right, and is blocked by a wall, we also 
want him to look like he's standing still, rather than walking in place. 


How will we know if Mario is blocked, on the left, by a wall (a Plat form object)? Mario is blocked, 
on the left, by a wall, when BOTH of the following are true: 


¢ The left side of Mario's rectangle is exactly one pixel to the right of the wall's right side. 
¢ Mario's vertical extent (the range of pixels from the top of Mario's rectangle to the bottom of his 
rectangle) shares at least one pixel with the wall's vertical extent. 


Notice how this is similar to how we check whether Mario is on top of a platform. Let's use our Range 
class, to get Mario's vertical extent. Add the following method to your Mario class: 


public Range verticalExtent () 
{ 
return new Range(myTop(), myBottom()); 


} 


Our Platform class will also require this method, so go to your Platform. java source file, and 
add it to Plat form. Now, we'll be able to check whether Mario is blocked, on the left, by a wall. Go 
back to your Mario.java source file. Add the following method to your Mario class: 


public boolean isBlockedByALeftWall () 
{ 
return myLeft() == WalkingMario.plat.myRight() + 1 && 
verticalExtent().overlaps (WalkingMario.plat.verticalExtent ()); 


} 


Similarly, we can check if Mario is blocked, on the right, by a wall, by checking whether BOTH of the 
following are true: 


¢ The right side of Mario's rectangle is exactly one pixel to the left of the wall's left side. 
¢ Mario's vertical extent shares at least one pixel with the wall's vertical extent. 


To implement this check, add the following method to your Mario class: 


public boolean isBlockedByARightWall () 
{ 
return myRight() == WalkingMario.plat.myLeft() - 1 && 
verticalExtent().overlaps (WalkingMario.plat.verticalExtent()); 


} 


Now, we'll be able to change how Mario moves left and right. First, go to your moveLeft method. 
Right now, its body looks like: 


an. (1 faeing £ight) 
{ 
frame = frame + 1; 
if (frame > FRAME WALK LAST) 
frame = FRAME WALK FIRST; 


hy rect.« = thy rect.x = 1; 
} 
elsé 

turnAround () ; 


If Mario is already facing left, he'll animate (advance in his walk cycle) and then "directly" move left 
one pixel. If Mario is currently facing right, he'll turn around. We want to change this, so that he doesn't 
move "directly", but only animates and intends to move left, when he is not blocked, on the left, by a 
wall. If he's blocked, on the left, by a wall, we want him to stand still. In yourmoveLeft method, 
change ... 


frame = frame + 1; 
if (frame > FRAME WALK LAST) 
frame = FRAME WALK FIRST; 


my recl.s = my rect.x — 1; 
.. to: 


if (!isBlockedByALeftWall ()) 
{ 
frame = frame + 1; 
if (frame > FRAME WALK LAST) 
frame = FRAME WALK FIRST; 


- Velocity = =2; 
: 
else 

standStill(); 


I decided to make Mario move faster: the x component of his velocity vector will be —2, rather than —1. 
Now, if the player wants to move left, Mario will only animate, and try to move left two pixels, if he is 
not blocked, on the left, by a wall. Technically, our moveLeft method should now be called 
something like "intendToMoveLeft", but we'll leave the method's name alone, so we don't have to 
refactor code that calls moveLeft. 


Similarly, in yourmoveRight method, change ... 
frame = frame + 1; 


if (frame > FRAME WALK LAST) 
frame = FRAME WALK FIRST; 


hy Sel .k. my PrSect.e +: 17 
.. to: 


if (!isBlockedByARightWall () ) 
{ 
frame = frame + 1; 
if (frame > FRAME WALK LAST) 
frame = FRAME WALK FIRST; 


x velocity = +2; 
} 


else 
standStill(); 


Now, if the player wants to move right, Mario will only animate, and try to move right two pixels, if he 
is not blocked, on the right, by a wall. 


When Mario turns around or stands still, we don't want him to try to move left or right, so our 
turnAround and standStill methods will change a bit. Add the following line of code to your 
turnAround and standStill methods: 


x velocity = 07 


Notice how we don't touch the y component of Mario's velocity vector here. We manipulate the two 
components of the vector independently of each other. Whether we're falling or not has nothing to do 
with whether we're moving left, moving right, or doing neither. 


Finally, we want to make Mario respond to gravity properly. If he's on top of a platform, he won't "try 
to" fall, while if he's in the air (not on top of a platform), he'll "try to" fall a number of pixels equal to 
gravity. In your respondToGravity method, change ... 


if (!isOnAPlatform() ) 
My Kect.y = my rect.y + Gravity; 


.. tO: 


if (!isOnAPlatform() ) 


y_ velocity = gravity; 
else 
y velocity =. 


I added the else block, so that if Mario's fall is broken by a platform, the y component of his velocity 
will be reset to 0. Otherwise, he would probably keep "trying to" fall, since y velocity would 
probably contain the value of gravity, which it had been set to, when he was previously falling. 
When his fall is broken, we have to "clear" this part of Mario's state. 


Run your program. If you press the left and right arrow keys, Mario will walk (or run, depending on the 
speed of his animation) to the left and right, in place. He won't move left or right, and he won't fall 
toward the bottom of the screen. Good intentions are not enough! Now, we need to make Mario try to 
actually move at his intended velocity. 


Remember before, when I told you that things would get harder? Well, they're now about to get even 
MORE difficult! The second stage of our collision-detection algorithm will cause Mario to actually 
move. Mario will make several "sub-moves" of about one pixel each. If he "glitches into" a platform, 
we'll undo his last "sub-move", and stop him right there. My algorithm is NOT the best possible 
implementation of collision-detection, but it's much more robust than the one we tried to use before. If 
you are REALLY ambitious and knowledgeable (think MATH!), you can try to improve upon it! 


Before we implement my algorithm, we'll need a few more "convenience" methods. The first one will 
get the rectangle of a platform. Go to your Platform. java source file. Add the following accessor 
method to your Plat form class: 


public Rectangle myRect () 
{ 


return my rect; 


} 


Now, we'll need a method that will check whether Mario is "glitched into" a platform or not. Go back 
to your Mario. java source file. Add the following method to your Mario class: 


public boolean isInAPlatform() 
{ 


relurn my rect.intersects (WalkingMario.plat .myRect ())/ 


} 


The above method just calls the intersects method of Java's built-in Rectangle class, which 
checks if two rectangles intersect (share at least one pixel, or overlap). Now, we are FINALLY ready to 
write the code that will make Mario move at his intended velocity, taking into account any obstacles in 
his way! Add the following method to your Mario class: 


public void actuallyMove () 
{ 
} 


I will guide you through the implementation of this method, step by step. Along the way, I will explain 
what the code does. Add the pieces of code to the actual 1lyMove method in the order in which I 
specify them here. First, add the following code to your actuallyMove method: 


if (x_velocity == 0 && y velocity == 0) 
recur; 

else if (isInAPlatform()) 

{ 
my rect.* = my rect.x + x velocity; 
my SEC. my rect.y + y velocity; 
Fevuri; 


} 


kg 
II 


These blocks of code cover two special situations for our collision-detection algorithm. If Mario does 
not intend to move at all, on this tick, no collision-detection has to be done. The second situation, 
Mario being "glitched inside of" a platform, should never happen, but if it does, I want the player to be 
able to become unstuck. Therefore, if Mario is "glitched inside of" a platform, we'll just have him move 
the entire distance he intends to move, on that tick. He'll do that, until he becomes unstuck. After that, 
he'll move normally (not as if there are no potential obstacles in his way). Next, we'll need to gather a 
few pieces of information about Mario's velocity, using the following code: 


int mag xv = Math.abs(x velocity); 


int sign xv = 0; 
If (x velocity t= 0) 

sign xv = x velocity / mag_xv; 
int mag _yv = Math.abs(y velocity); 


cr ¢ 


int sign yv = 0; 
ax (y velocizy t= 0) 
sign_yv = y_ velocity / mag_yv; 


Here, we get the signs (—1 if the number is negative, 0 if the number is zero, +1 if the number is 
positive) and magnitudes (absolute values) of the components of Mario's velocity vector. The following 
formula always holds true, fora number: signXmagnitude=number_. Then, we'll need some more 
information about Mario's velocity. Add the following code: 

boolean mxv_ larger = false; 
if (mag _xv > mag_yv) 
mxv_larger = true; 


Here, we find out which component of Mario's velocity vector has a larger magnitude: the x component 
or the y component. If both components have the same magnitude, it won't matter which one we say is 
larger. This code will say that the y component has a larger magnitude, by default. Lastly, before Mario 
begins to actually move, we'll need to initialize some values that will direct his sequence of "sub- 
moves". Add the following code: 
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big velocity = 0; 
small velocity = 


0; 


if (mxv_larger) 


{ 


big velocity = mag xv; 
small velocity = mag_yv; 


} 


else 


{ 


big velocity = mag_yv; 
small velocity = mag_xv; 


} 


float small step = (float)small velocity / big velocity; 
float small pixels = 0; 


Our algorithm will divide Mario's movement into a number of "sub-moves". The number of "sub- 
moves" will be equal to the magnitude of the component of Mario's velocity with the larger magnitude. 
This number will get stored in big velocity. Mario will make up tobig velocity "sub- 
moves". The magnitude of the other component will get stored in small velocity. 


On each "sub-move": 


¢ Ifthe x component of Mario's velocity has a larger magnitude: 


ie) 


If the x component of his velocity is negative, Mario will move one pixel to the left. We 
could, therefore, call left his "big direction". If the x component is positive, Mario will move 
one pixel to the right (his "big direction"). 

Then, since the members of Mario's Rectangle object can only contain integers, we'll 
simulate him moving a fraction of a pixel: up, if the y component of his velocity is negative, 
or down, if the y component is positive. His "small direction" would be whichever one of 
these directions he moved in. 


¢ Ifthe y component of Mario's velocity has a larger magnitude: 


ie) 


If the y component of his velocity is negative, Mario will move up one pixel. We could, 
therefore, call up his "big direction". If the y component is positive, Mario will move down 
(his "big direction") one pixel. 

Then, since the members of Mario's Rectangle object can only contain integers, we'll 
simulate him moving a fraction of a pixel: left, if the x component of his velocity is 
negative, or right, if the x component is positive. His "small direction" would be whichever 
one of these directions he moved in. 


How will we simulate Mario moving a fraction of a pixel? First, we'll get the fraction of a pixel that we 
need by dividing small velocity bybig velocity, and storing the result in small step. 
The value of small step can be as low as 0 (if one of the components of Mario's velocity is 0), and 
as high as | (if both components have the same magnitude). 


A variable of type float can be used to store a real number, just like a variable of type double. 
However, a float takes up less memory, and may be a bit faster. You can use a float, instead of a 
doub1e, if you don't need as much precision in your result. 


To simulate Mario moving fractions of a pixel, we'll store a "running count" of how many pixels he has 
"moved", in his "small direction", in small pixels. On each "sub-move", small pixels willbe 
incremented by the value of small step. Ifsmall_ pixels becomes greater than or equal to 1, 
Mario will ACTUALLY MOVE one pixel in his "small direction". Then, small pixels will have 1 
taken away from it, to compensate for that actual motion. 


Look at the following diagram: 
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Let's say that Mario is moving at a velocity of (+4, +3). He intends to move 4 pixels left and 3 pixels 

down. The x component of his velocity has a larger magnitude (4), so his "big direction" is left, while 

his "small direction" is down. As you can see, his move, on this tick, can be divided into four "sub- 

moves" of 1 pixel left and *% of a pixel down. I colored the "sub-moves", in the diagram, red and black, 
25 


2 
so that you could see each one. Each of these moves is | (1)°+ (3) =| 767125 pixels in length. 


Four times 1.25 is 5, which is Mario's speed, in pixels per tick. 


Finally, we'll write the code that will make Mario ACTUALLY MOVE! Add the following code: 


for (int i = 0; i < big velocity; i = i + 1) 
{ 


boolean made small stép = false; 


if (mxv_larger) 

{ 
my rect.* = my rect.x + (sign av * 1); 
small pixels = small pixels + small step; 


ae (small pixeles >= 1) 
{ 


my rect.y = my rect.y + (sign yy * 1); 
small pixels = small pixels = 1; 
made small step = true; 
} 
} 
eles 


{ 
my rect.y = my rect.y + (sign yy * 1); 
small pixels = small pixels + small step; 


ae (emel | ‘pixels >= 1) 
{ 


my rect.x = my rect.x + (sign xv * 1); 
small pixels = small pixels - 1; 
made small step = true; 


} 


if (1sInAPlatform() ) 


if (mxv_larger) 
af 


ny rect. x = My rect. x = (eign ay * 1); 


if (made_small_ step) 
my rect.y = my rect.y = (sign yv * 1); 
} 


else 


{ 


ny rect.y = my rect.y =— (aiqn- yr * )7 
if (made_small_ step) 
my rect. = my rech.s — (sign xy * 1); 


} 


break; 


The size of this piece of code is inflated by the checks for whether the x component of Mario's velocity 
has a larger magnitude. I will explain what this code does, piece by piece. I already discussed where the 
value of big velocity came from: the magnitude of the component of Mario's velocity with the 
larger magnitude. Mario will make up to big velocity "sub-moves", so this for loop will run at 
most big velocity times. 


The first part of each "sub-move" will consist of Mario moving one pixel in his "big direction" (We 
could call that a "big step".) and possibly one pixel in his "small direction" (We could call that a "small 
step".). If Mario gets "glitched into" a platform, on this "sub-move", we'll need to undo this "sub- 
move". This "undo" operation will consist of Mario moving one pixel back, in his "big direction", and 
possibly one pixel back, in his "small direction". In order to know whether Mario will need to move 
back, in his "small direction", we'll need to know whether Mario moved in his "small direction", on this 
"sub-move". Therefore, we'll keep track of whether that happened, using the variable, 

made small step. 


I already covered how Mario will perform each of his "sub-moves". However, I'll clarify some of the 
math here. We separated each component of Mario's velocity into a sign and a magnitude, near the 
beginning of this method. The sign is used here, to ensure that Mario moves in his intended direction, 
each time he moves. Let's analyze a statement, like the following one: 


ny rect .& = my recl.e + (eign xy Fol); 
This statement says "Add —1, 0, or +1 to the x-coordinate of Mario's left side, depending on whether he 
is moving left, not at all, or right, in the x direction." By storing the sign of the x component of Mario's 


velocity in sign_ xv, and multiplying it by 1 (not necessary, but put there, to say that we're going to 
move Mario one pixel), we eliminate an if statement, which would look like: 


If (x velocity > 0) 


ny -tecl.s = my Kectlse ar 17 
else 1 (x velocity < 0) 
ny - recth.© = my - rect. = 1; 


// If * velocity is 0, we den’t need to do anything here. 


This collision-detection code already has a bad enough code duplication problem. Eliminating 
repetitive if statements is a step in the right direction. Code duplication is the writing (or copying and 
pasting) of many instances of the exact same or similar code. Normally, you should try to avoid 
duplicating code, by writing methods that perform common tasks. 


The second part of each "sub-move" will consist of checking whether Mario is now "glitched into" a 
platform. If he is, we'll undo that "sub-move", and stop trying to make any more "sub-moves", since 
each of them would cause the same thing to happen again. Have you ever seen one of those "dumb 
robots" that keeps running into a wall, backing up a bit, and then running into that same wall again? 
Albert Einstein said, "Insanity is doing the same thing over and over again and expecting different 
results." Source: http://www.brainyquote.com/quotes/authors/a/albert_einstein. html. 


To undo a "sub-move", we do the opposite of what we did to make that "sub-move". To undo a "big 
step", we use a statement, like: 


my rect.x% = my rect.x - (sign xv * 1); 


To make the "sub-move", we added (sign xv * 1) to the x-coordinate of Mario's left side. 
Therefore, to undo the "sub-move", we must subtract that quantity from the x-coordinate of Mario's left 
side. This is because subtraction is the opposite of addition. To undo a "small step", we first have to 
check whether we made one. If we made one, we undo it, using a similar statement. Finally, to stop 
trying to make any more "sub-moves", we use a break statement, to break out of our for loop. 


Whew! You have just finished coding possibly the most complex algorithm you have ever coded! If 
Budents have trouble understanding it, draw more pictures, to explain it more Lia ee 
one more thing we have to do. Nothing calls our actuallyMove method yet! 


Go to your TimerEventProcessor. java source file. The body of the actionPerformed 
method of your TimerEventProcessor class should look like: 


WalkingMario.mario.act(); 
WalkingMario.goom.act(); 
WalkingMario.main window. repaint (); 


On each tick of the timer, we want Mario to perform the two stages of his movement. First, we want 
him to intend to move at a given velocity (done by our call to his act method). Then, we want him to 
try to actually move at that velocity. This will be done by a call to Mario's actuallyMove method. 
Before your call to repaint ... 


WalkingMario.main window.repaint(); 

... insert: 

WalkingMario.mario.actuallyMove(); 

The body of your actionPerformed method should now look like: 


WalkingMario.mario.act(); 
WalkingMario.goom.act(); 


WalkingMario.mario.actuallyMove(); 
WalkingMario.main window. repaint (); 


Run your program. Mario should now land on the platform. Whether he's in the air, or on the platform, 
he should move left and right, when you press left and right arrow keys. Try changing Mario's 
velocity, his starting position, and the position of plat. If he moves really fast (if you set his 
gravity to 100, for instance), does he fall through the platform? Try to "break" my collision- 
detection code. To "break" a piece of code is to cause it to not work properly, under some set of 
conditions (without changing the actual code itself). This kind of "destructive testing" can be 
used to find potential bugs in code. To slow down Mario's motion, so that you can see him move, 
frame by frame (though not his "sub-moves"), go to your WalkingMario. java source file. In 
this line of code: 


timer = new Timer(20, new TimerEventProcessor() ) ; 
Change the 20 to something like 500, to slow down his movement and animation. Before you 


change any code, though, you might want to save a backup copy first, in case you mess something up, 
and don't know how to fix it. 


